Every certificate issued by a certification authority (CA) has a validity period. The validity period is the range of time where the certificate can be accepted as an authoritative credential of the identity of the subject of the certificate. This is, of course, assuming the certificate is not revoked before the validity period ends and that the issuing CA is trusted. The primary purpose of the validity period is to limit the time in which a certificate is exposed to the possibility of being compromised.
Since a CA is really just another entity that has been issued a
Before discussing the renewal of a CA certificate, it is helpful to understand how the end of the validity period of a CA affects the validity period of the certificates it issues. Certificate Services enforces a rule that a CA never issues a certificate to be valid beyond the expiration date of its own certificate. Therefore, when a CA's certificate reaches the end of its validity period, all certificates it has issued will also expire. This way, if the CA is purposely not renewed and the CA reaches the end of its lifetime, a PKI administrator can be assured that all the certificates that the now-expired CA has issued can no longer be used as valid security credentials. In other words, there will be no "orphaned" certificates that are still within their validity period but which have been issued by a CA that is no longer valid.
To illustrate how a decreasing validity period works, consider the following scenario: An organization installs a root CA with a certificate validity period of five years. The organization then uses this root CA to issue certificates with a validity period of two years to subordinate CAs. For the first three years every certificate issued to a subordinate CA by the root CA will continue to have a validity period of two years. After three years, when there is less than two years left in the validity period of the root CA certificate, Certificate Services begins to reduce the validity period of the certificates issued by the root CA so that they do not exceed the end of the CA's certificate's expiration date. Therefore, after four years, the CA issues subordinate CA certificates that are valid for one year. After 4.5 years, issued subordinate CA certificates have a validity period of only six months.
Certificate Services allows for the following maximum validity periods that are based on the type of certificate. These validity periods are configurable by the Domain Admin or Enterprise Admin when using version 2 certificate templates:
| Type of certificate | Maximum validity period |
|---|---|
| Root CA | Specified during setup of Certificate Services |
| Subordinate CA, Internet Protocol Security, Enrollment Agent, Domain Controller | Up to 5 years, never more than the Root CA's validity period |
| All other certificates | 1 year, never more than the Root CA's validity period |
Since a CA that is approaching the end of its own validity period issues certificates valid for shorter and shorter periods of time, you need to have a plan in place to renew the CA well before it expires in order to avoid issuing certificates of a very short validity period.
One renewal consideration: When you renew a CA, you have the option of reusing its existing key pair or generating a new key pair. When you generate a new key pair for a CA that is being renewed, a new certificate revocation list (CRL) distribution point is also created. This is to ensure that the key used to sign a certificate issued by the CA also matches the key used to sign the CRL. For more information about how renewing a CA with a new key affects certificate revocation and the name of CRLs, see Revoking certificates and publishing CRLs.
The following strategies are presented as possible approaches an organization could take when planning for CA renewal. You may need to adapt these to your specific situation.
Since the root CA is the most critical CA in the hierarchy, you may prefer to have a strategy here that reduces the need to renew the root certificate often.
The first consideration is choosing the key length of the root's public key and private key pair during setup of the root authority. By using a long key length, which is generally more secure against brute force attack by a hacker than a shorter key length, you increase the length of time that the CA can use the same private key and have reasonable confidence that it has not been compromised. The second consideration is establishing the validity period of the root certificate itself. In general, you will want to create a root certificate that has a shorter validity period than the estimated lifetime of the key.
Keeping these considerations in mind, a possible strategy for setting up a root CA that reduces the need for frequent renewal would be to create a 4096-bit RSA key during Certificate Services setup. Given the current state of computer technology, one estimate is that a 4096-bit private key is reasonably secure from a brute force attack for 15-20 years. After creating the 4096-bit key in Certificate Services setup, you could create a root certificate using the 4096-bit key that is valid for five years. Afterwards, the CA's certificate should be renewed every four years (one year before the expiration of the validity period), each time with a certificate validity of five years. Of course, every time the CA certificate is renewed, the administrator will have to assess whether the same key, given current computer technology and other security considerations, can be used with confidence for the next five years.
Within an organization's certification hierarchy, some subordinate CAs may be "intermediate"
For subordinate CA's that do issue certificates to end users and computers, sometimes referred to "issuing" CAs, a preferable strategy may be to renew the CA's certificate regularly with a new key 6-12 months before the end of the CA's validity period, for example. This makes an attack by a hacker on any one key less valuable, since any compromised key would have a relatively limited lifetime.
The other advantage of renewing an issuing CA using a new key is CRL management. When a CA is renewed with a new key, it begins to publish a separate CRL for the revoked certificates it has issued using the new key. It also will continue to publish a CRL for certificates signed with the old key, for as long as those revoked certificates validity period is still in effect. This is something a CA administrator may want to exploit if the CA is issuing a large number of certificates and, potentially, revoking a large number of those certificates. It may be advantageous to reduce the possibility of having one huge CRL that certificate verifiers have to download. Instead, issue a number of certificates with one key, renew the CA early into its validity period with a new key, then issue a number of certificates using the new key. In this way, you will reduce the size of the CRL that the certificate verifier has to download when presented with a certificate from an issuing CA.
For more detailed information about planning for renewal and renewing Microsoft certification authorities, refer to the Windows Deployment and Resource Kits.
For the procedure to renew a root CA, see Renew a root certification authority.
For the procedure to renew a subordinate or intermediate CA, see Renew a subordinate certification authority.